home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3176 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.1 KB  |  117 lines
  1. Path: news.mountain.net!usenet
  2. From: gene_heskett@wvlink.mpl.com (Gene Heskett)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 08 Feb 96 00:45:46 +0500
  6. Organization: MountainNet, Inc. Morgantown WV 800.444.1458
  7. Message-ID: <4788.6612T45T2348@wvlink.mpl.com>
  8. References: <john.hendrikx.4bpe@grafix.xs4all.nl>
  9. NNTP-Posting-Host: slip1.mpl.com
  10. X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
  11.  
  12.  
  13. Sorry to repeat here but this post *was* a lot longer:
  14.  JH> In a message of 03 Feb 96 Peter McGavin wrote to All:
  15. [snip]
  16.  JH> 'easy' parameter checking).  But even memory protection which
  17.  JH> just protects programs from each other by not allowing them to
  18.  JH> share the same memory would kill our current message system.
  19.  
  20. Whats wrong with PIPEs?  Yeah, I know, the present Miggi pipe sucks...  But
  21. *real* pipes can handle that just fine.
  22.  
  23.  JH> I think copying messages isn't as big an impact as some people
  24.  JH> think, after all, a good copying routine can copy over 200K every
  25.  JH> 1/50 of a second.
  26.  
  27. Qualify that with "flat" memory please. AFAIK, no PIPE can do that on *any*
  28. dat or mmu equipt machine. Well, maybe on an Alpha...
  29.  
  30. I'm a relative neophyte here people, but I doubt 1 thing and thats the size
  31. increase of the opsys WITH memory protection.  With hardware on the job,
  32. dat or mmu, I don't see that it should add more than 10K of *pure* code,
  33. and scratchpad space comensurate with what it has to remember.  But at my
  34. level of expertise, I'm sure not going to volunteer to do that upgrade.  I
  35. base my assumptions on the amount of actual code to incorporate a hardware
  36. dat setup in another 8 bit opsys, maybe, just maybe 3k or *pure* code, and
  37. maybe 2 kilobytes of scratchpad!  With 20+ window.devices/processes/tasks
  38. open at the same time! None of which has access to another processes memory
  39. unless specifically written into that process, and then its only available
  40. thru opsys calls. The opsys itself isn't even visible to the process except
  41. thru a software interrupt protocol.
  42.  
  43. [snip]
  44.  
  45.  PM>> advantage over other OSes.  In the latter case we'd might as
  46.  PM>> well move to another OS.  In both cases AmigaOS loses its
  47.  PM>> performance edge over other OSes.
  48.  
  49. Which taking it out of C source and into asm would cancel IMO. I have beat
  50. the compiler at times (on that other opsys) by hand editing the asm source
  51. it outputs.  There may be enough speed there to make it back up.
  52. [snip]
  53.  
  54.  JH> what's out there, all I know is that memory-protection is a MUST
  55. [snip]
  56.  
  57. I have to agree. I'm sick of the crashes from just one of maybe 80 tasks
  58. running here thats not able to handle its exceptions right. And I *do* have
  59. a 2630 with a working mmu. But, the memory map is still flat, and it still
  60. crashes.  The question then is "which one of those 80 or so tasks ARTM
  61. reports is the baddy?" The answer is usually "damnifiknow", and the 3
  62. finger salute handles it fairly well if repeated enough times in a row.
  63.  
  64. I might add that in recent weeks the mmu has saved me several times. My
  65. agnus socket was going flaky and the video was crashing. Several times a
  66. night. It was weird to see the screen totally munged into confetti, while a
  67. process, in these cases THOR, continued to run to completion, getting my
  68. 20 mails and 300 news's. Only when the modem and hard drive got quiet did I
  69. reboot to recover the screens video. No damage was done AFAIK.
  70.  
  71. [snip]
  72.  
  73.  PM>> port of AmigaOS to PPC and practically all compatibility with
  74.  PM>> existing software would be lost.
  75.  
  76. Thats not a given! With the exception of one hardware gfx mode lost in the
  77. new chips for the machine at the "add memory management" transition, there
  78. is nothing AFAIK written for the old version of that system that doesn't
  79. now run just as well on the "with memory management" system.
  80.  
  81. [snip]
  82.  
  83.  JH> Then after 1 or 2 years (ie, in 1998/99) the 2nd release (OS4.1)
  84.  
  85. Lapsing into the customers vernacular here:
  86. Ya mean 2 years down the log I gotta replace 10+ kilobucks worth of proggies
  87. IF I wanna run the new OS? Ya gotta be dreamin! What are you smokin, I
  88. *want* some of that! This market is not always dictated to by the
  89. programmers, sometimes the potential customer (me) sends very loud messages
  90. when he doesn't buy what the programmers are offering.  Remember that when
  91. you use words like "force", and "obsolete".  If an obsolete opsys running
  92. an obsolete program does the job in a timely manner to our
  93. customers/clients satisfaction, we sure aren't going to fix what ain't
  94. broke!
  95.  
  96. [snip]
  97.  
  98.  JH> a reasonable time-span).  OS4.0 would basicly be the OS which
  99.  JH> runs both OS3.1 programs and OS4.1 programs.  OS4.1 would only
  100.  JH> run OS4.0 compliant programs and all new programs.
  101.  
  102. Drawing the line that precisely? Big job. Now who gets elected to be
  103. Solomon?
  104.  
  105. [s.. , heck you know the drill by now]
  106. The rest of that gets into stuffs I really don't know about, but I'm
  107. studying on as the need to know arises.
  108.  
  109. Just a sometimes programmer, and professional customers $.02 worth.
  110.  
  111. /*            Gene Heskett          |  These opinions are NOT to be  */
  112. /*  CE @ WDTV Weston/Clarksburg WV  |  confused with the official    */
  113. /*  <gene_heskett@wvlink.mpl.com>   |  WDTV managment views          */
  114. #include <std.disclaimer>
  115.  
  116.  
  117.